Re-designing Dynamic Content Delivery in the Light of a Virtualized Infrastructure

We explore the opportunities and design options enabled by novel SDN and NFV technologies, by re-designing a dynamic Content Delivery Network (CDN) service. Our system, named MOSTO, provides performance levels comparable to that of a regular CDN, but does not require the deployment of a large distributed infrastructure. In the process of designing the system, we identify relevant functions that could be integrated in the future Internet infrastructure. Such functions greatly simplify the design and effectiveness of services such as MOSTO. We demonstrate our system using a mixture of simulation, emulation, testbed experiments and by realizing a proof-of-concept deployment in a planet-wide commercial cloud system.Comment: Extended version of the paper accepted for publication in JSAC special issue on Emerging Technologies in Software-Driven Communication - November 201

Cellular access multi-tenancy through small-cell virtualization and common RF front-end sharing

Mobile traffic demand is expected to grow as much as eight-fold in the coming next five years, putting strain in current wireless infrastructures. Meanwhile the diversity of traffic and standards may explode as well. One of the most common means for matching these mounting requirements is through network densification, essentially increasing the density of deployment of operators’ base stations in many small cells and handling timing critical traffic at the edge. In this paper we take a step in that direction by implementing a virtualized small cell base station consisting of multiple, isolated LTE PHY stacks running concurrently on top of a hypervisor deployed on a cheap, off-the-shelf x86 server and a shared radio head. In particular, we show that it is possible to run multiple virtualized base stations while achieving throughput equal or close to the theoretical maximum. In contrast to C-RAN (Cloud/Centralized Radio Access Network), our virtualized small cell base station has full stack at the edge so that a low latency high throughput front-haul, which is necessary in C-RAN architecture, is not needed. This approach brings all the flexibility and configurability (from network management point of view) that a software based implementation provides while the transparent architecture enables the possibility of multiple standards sharing the same radio infrastructure.The projects leading to this paper has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no. 67156 (Flex5Gware), no. 732174 (ORCA project) and no. 761536 (5G-Transformer)

Flowstream Architectures

The Internet has seen a proliferation of specialized middlebox devices that carry out crucial network functionality such as load balancing, packet inspection or intrusion detection, amongst others. Traditionally, high performance network devices have been built on custom multi-core, specialized memory hierarchies, architectures which are well suited to packet processing. Recently, commodity PC hardware has experienced a move to multiple multi-core chips, as well as the routine inclusion of multiple memory hierarchies in the so-called NUMA architectures. While a PC architecture is obviously not specifically targeted to network applications, it nevertheless provides high performance cheaply. Furthermore, a few commodity switch technologies have recently emerged offering the possibility to control the switching of flows in a rather fine grained manner. Put together, these new technologies offer a new network commodity platform enabling new flow processing and forwarding at an unprecedented flexibility and low cost

FlexOS: Towards Flexible OS Isolation

At design time, modern operating systems are locked in a specific safety and isolation strategy that mixes one or more hardware/software protection mechanisms (e.g. user/kernel separation); revisiting these choices after deployment requires a major refactoring effort. This rigid approach shows its limits given the wide variety of modern applications' safety/performance requirements, when new hardware isolation mechanisms are rolled out, or when existing ones break. We present FlexOS, a novel OS allowing users to easily specialize the safety and isolation strategy of an OS at compilation/deployment time instead of design time. This modular LibOS is composed of fine-grained components that can be isolated via a range of hardware protection mechanisms with various data sharing strategies and additional software hardening. The OS ships with an exploration technique helping the user navigate the vast safety/performance design space it unlocks. We implement a prototype of the system and demonstrate, for several applications (Redis/Nginx/SQLite), FlexOS' vast configuration space as well as the efficiency of the exploration technique: we evaluate 80 FlexOS configurations for Redis and show how that space can be probabilistically subset to the 5 safest ones under a given performance budget. We also show that, under equivalent configurations, FlexOS performs similarly or better than several baselines/competitors.Comment: Artifact Evaluation Repository: https://github.com/project-flexos/asplos22-a

Loupe: Driving the Development of OS Compatibility Layers

Supporting mainstream applications is fundamental for a new OS to have impact. It is generally achieved by developing a layer of compatibility allowing applications developed for a mainstream OS like Linux to run unmodified on the new OS. Building such a layer, as we show, results in large engineering inefficiencies due to the lack of efficient methods to precisely measure the OS features required by a set of applications. We propose Loupe, a novel method based on dynamic analysis that determines the OS features that need to be implemented in a prototype OS to bring support for a target set of applications and workloads. Loupe guides and boosts OS developers as they build compatibility layers, prioritizing which features to implement in order to quickly support many applications as early as possible. We apply our methodology to 100+ applications and several OSes currently under development, demonstrating high engineering effort savings vs. existing approaches: for example, for the 62 applications supported by the OSv kernel, we show that using Loupe, would have required implementing only 37 system calls vs. 92 for the non-systematic process followed by OSv developers. We study our measurements and extract novel key insights. Overall, we show that the burden of building compatibility layers is significantly less than what previous works suggest: in some cases, only as few as 20% of system calls reported by static analysis, and 50% of those reported by naive dynamic analysis need an implementation for an application to successfully run standard benchmarks.Comment: Accepted to appear at ASPLOS'24 (https://www.asplos-conference.org/asplos2024/